Problem

RcppParallel 6.0.0 (via #241) stopped loading any TBB library in .onLoad on Windows, on the grounds that TBB is statically linked there. However, we still ship a stub tbb.dll (see src/install.libs.R) for packages that link with -ltbb, e.g. via StanHeaders' LdFlags(). Those packages record a load-time dependency on tbb.dll in their DLL's import table, and the Windows loader can only resolve that against an already-loaded module -- RcppParallel's lib/x64 directory is not on the DLL search path (and -Wl,-rpath is a no-op in PE binaries).

As a result, with 6.0.0 on Windows, Stan-based packages fail their install-time load test with:

unable to load shared object '...WSPsignal/libs/x64/WSPsignal.dll':
  LoadLibrary failure:  The specified module could not be found.

Seen with e.g. WSPsignal on r-universe: https://github.com/r-universe/cran/actions/runs/30028540221/job/89334243681

Pre-built binaries that import tbb.dll (the original motivation for the stub, per the comment in src/install.libs.R) are affected the same way.

Verified against the r-universe RcppParallel_6.0.0.zip Windows binary: it ships only libs/x64/RcppParallel.dll (which exports the oneTBB r1 runtime symbols) and lib/x64/tbb.dll (the stub, self-contained), so -ltbb direct-links the stub and the resulting import can never resolve without a preload.

Fix

Restore the .onLoad preload of the stub on Windows. The stub is resolved directly via tbbRoot() rather than tbbLibraryPath(), since #241 repurposed the latter to report static library names on Windows.

Notes

• Parked on its own branch like guard bundled tbb against gcc cpuid.h / mingw intrin.h conflict #248 while the 6.0.1 submission gets sorted out; the 6.0.1 release as submitted was canceled in favor of including this fix.
• Only tbb.dll is shipped on Windows, so loadTbbLibrary("tbbmalloc") still returns NULL there, as before.